\chapter{Tests f"ur die Implementierung der NOP-Engine}\label{chapter:test}
\input{chapters/test/figuresTables}
Im folgenden Kapitel werden die bei der Implementierung parallel ausgef"uhrten Tests zur Verifikation der Korrektheit der Funktionalit"aten der NOP-Engine vorgestellt. Es wird eine detaillierte  Beschreibung der Test-Technologien bzw. der modernen Java-Werkzeuge gegeben, mit denen die vordefinierten Testf"alle implementiert werden.
\section{Hintergrundinformationen zu Softwaretests}
{\bf Softwaretests} sind eine Technologie der Softwareentwicklung, um die Funktionalit"at einer Software an den Anforderungen und ihrer Qualit"at zu messen, und Softwarefehler zu ermitteln.  Die Ziele von Softwaretests sind nach \cite{Pat05} insbesondere:
\begin{itemize}
\item Bugs so fr"uh wie m"oglich herauszufinden, und
\item sie zu beheben.
\end{itemize}
Mit angemessenen Softwaretests ist die Korrektheit der Funktionalit"at eines Programms garantiert. Zum Messen der Funktionalit"aten der NOP-Engine an den Anforderungen werden in unserem Projekt zwei Softwaretests angewendet: Modul- und Integrationstests.

\subsection{Modultests}
{\bf Modultests} (auch {\em Komponententests} oder engl. {\em unit tests}) sind ein Teil des Softwaretests. Bei Modultests konzentrieren sich Tester (oder Programmierer) nicht auf das ganze System, sondern auf seine Module, Funktionen, Klassen sogar Teil-Systeme \cite{lin02}. Ein Modultest ist selbst ein Programm und dient zur Verifikation der Korrektheit von Modulen einer Software. Dazu m"ussen externe Komponenten wie etwa eine Datenbank, Dateien oder Backendsysteme, die von Modulen verwendet werden, entweder in einen vordefinierten Zustand gebracht oder durch Mock-Objekte \cite{Freeman09} simuliert werden, damit das Modul in jedem Fall die erwarteten Auswirkungen hat. Dar"uber hinaus soll aber noch ausdr"ucklich die korrekte Behandlung nicht korrekter Eingabewerte gepr"uft werden.\\\\
Trotz der Betonung ihrer Wichtigkeit in der Testliteratur spielten Modultests lange Zeit f"ur die meisten Entwickler eine mehr als untergeordnete Rolle. Dies "anderte sich, als Extreme Programming \ab{XP} \cite{Beck00} die Durchf"uhrung von Komponententests zu einer zentralen T"atigkeit werden lie"s. Dabei wurde eine neue Test-Technologie, die sogenannte testgetriebene Softwareentwicklung, entwickelt. 
Bei der {\bf testgetriebenen Softwareentwicklung} \engl{Test-Driven Development kurz. TDD} handelt es sich um ein Vorgehen bei der Kodierung von Softwaresystemen, das aus dem Streben der XP-Entwickler nach vollst"andigen automatisierten Modultests hervorgegangen ist. Im Buch \cite{Beck03} von Kent Beck wird TDD folgenderma"sen beschrieben: "`Schreibe nur dann neuen Code, wenn ein automatisierter Test fehlschl"agt."'. Die Implementierung der Dom"anenschicht der NOP-Engine ist vollst"andig mit Modultests durch TDD testgetrieben.
\subsection{Integrationstests}
Im Vergleich mit Modultests liegt die Betonung bei {\bf Integrationstests} auf Softwaretests, die die Korrektheit eines Teilsystems mit einer Reihe von Modulen verifizieren \cite{Pat05}.
Integrationstests konzentrieren sich auf Interaktionen zwischen mehreren Systemcontrollern \cite{Fisher08}, die aus der objektorientierten Sicht als Objekte oder Fassaden \cite{Gamma94} von Objekten genannt werden, um Anwendungsf"allen auf Anforderungen zu "uberpr"ufen. "Ublicherweise sollen Integrationstests nach Modultests und vor Systemtests durchgef"uhrt werden.

\subsection{Klassentests}
Modul- und Integrationstests bei der Entwicklungsphase sind sich manchmal schwer zu unterscheiden. In dieser Arbeit wird ein Kompromiss angewendet, n"amlich {\bf Klassentests} \engl{Class Testing} \cite{Ambler98}. Bei Klassentests handelt es sich um die Tests, die Klassen als Test-Einheiten betrachten. Um eine Klasse $A$ zu testen wird die Zusammenarbeit von $A$ und den Klassen $B, C, \ldots$ , von denen $A$ abh"angig ist, getestet. Solche Tests sind  f"ur die Klasse $A$ Modultests und  f"ur $A, B, C, \ldots $ zusammen Integrationstests.\\\\ Dieses Konzept wird eingef"uhrt, weil manche Modultests in dieser Arbeit  keine reinen Modultests sind, sondern Klassentests. Jedoch werden sie trotzdem einheitlich als Modultests bezeichnet, um sie leichter beschreiben und verstehen zu k"onnen.

\section{Java-Werkzeuge f"ur Modul- und Integrationstests}
Dank der JAVA-Community und Anbietern der quelloffenen \engl{open source} Bibliotheken kann man eine gro"se Auswahl f"ur Softwaretests in der JAVA-Welt finden. In dieser Arbeit werden \kc{JUnit,}\kc{JMock}und das Test-Paket von \kc{Spring}angewendet, um die automatisierten Modul- und Integrationstests f"ur die Implementierung der NOP-Engine aufzubauen. 
\subsection{JUnit}
{\bf JUnit} ist ein Framework zum Testen von Java-Programmen, das besonders f"ur automatisierte Modultests einzelner Modulen (meist Klassen oder Methoden) geeignet ist. Es basiert auf Konzepten, die urspr"unglich unter dem Namen SUnit f"ur Smalltalk entwickelt wurden.
Ein {\em JUnit}-Test kennt nur zwei Ergebnisse: Entweder der Test gelingt (dann ist er gr"un) oder er misslingt (dann ist er rot). Das Misslingen kann als Ursache einen Fehler (Error) oder ein falsches Ergebnis (Failure) haben. Das Ziel der {\em JUnit}-Tests ist eine gr"une Farbe f"ur alle Tests zu erhalten.
\subsubsection{Annotationen}
Ab der Version 4.0 werden {\em JUnit}-Tests vollst"andig von den Annotationen unterst"utzt. Von der Definition einer Test-Klasse bis zur Deklaration einer Test-Methode. Die folgenden Annotationen werden in den Tests dieser Arbeit verwendet:
\begin{itemize}
\item \anno{RunWith}dient dazu, eine spezielle Implementierung des Interfaces {\em Runner} f"ur eine Test-Klasse anzuwenden.
\item \anno{Test}bezeichnet eine Methode als einen {\em JUnit}-Test.
\item \anno{Before}deklariert eine Methode, die vor der Ausf"uhrung jedes Tests ein Mal ausgef"uhrt werden soll.
\item \anno{After}deklariert eine Methode, die nach der Ausf"uhrung jedes Tests ein Mal ausgef"uhrt werden soll.
\item \anno{BeforeClass}beschreibt eine statische Methode, die vor allen Tests einer Test-Klasse nur einmalig ausgef"uhrt werden soll. 
\item \anno{AfterClass}bezeichnet eine statische Methode, die nach allen Tests einer Test-Klasse nur einmalig ausgef"uhrt werden soll.
\item \anno{SuiteClasses}definiert eine Klasse als eine Menge von mehreren definierten Test-Klassen, und f"uhrt alle Tests solcher Test-Klassen nacheinander anhand der Reihenfolge der Definition durch.
\end{itemize}
\subsubsection{Assertion}
Eine {\bf Assertion} \engl{assertion} ist eine Aussage "uber den Zustand eines Computer-Programms. Mit Hilfe von Assertionen k"onnen logische Fehler im Programm oder Defekte in der umgebenden Software erkannt werden. In Modultests spielen Assertionen eine Rolle, durch die die Vergleiche der realen Ergebnisse mit den erwarteten Werten erm"oglicht werden.\\\\
In {\em JUnit} werden f"ur Assertionen eine Reihe von {\em assertXXX} Methoden zur Verf"ugung gestellt.
Die Methoden, die am h"aufigsten in den Tests dieser Arbeit verwendet worden sind, sind:
\begin{itemize}
\item {\em assertEqual(erwarteter Wert, realer Wert)},
\item {\em assertNotNull(objekt)}, und
\item {\em assertEqual(erwarteter Wert, realer Wert, toleranter Wert)}.
\end{itemize}
Die Parameter der ersten beiden Methoden k"onnen beliebige Java-Typen sein. Die erste Methode wird f"ur Vergleiche von zwei Objekten zur Verf"ugung gestellt. Die dritte Methode dient zur Verifikation der Korrektheit von Zahlen, sowie float, double und int, mit Rundungsfehler. Andererseits urteilt die Methode {\em assertNotNull}, ob das eingegebene Objekt gleich {\em null}\footnote{Ein Java-Objekt ist gleich {\em null}, d.h. dieses Objekt ist noch nicht initialisiert.} ist. Die drei Methoden kommen in den Tests dieser Arbeit "uberall zum Einsatz.
\subsection{JMock}
{\bf JMock} ist eine quelloffene Java-Bibliothek, die Mock-Objekte \cite{Freeman09} zur Unterst"utzung von {\em JUnit} dynamisch erstellen kann. Damit k"onnte sich ein Objekt, das noch nicht implementiert wurde, simulieren lassen.
\subsubsection{Mock-Objekte}\label{section:mo}
Bei {\bf Mock-Objekte} handelt es sich um Dummy-Objekte \cite{Link05} oder Attrappen, die in der testgetriebenen Softwareentwicklung als Platzhalter f"ur echte Objekte innerhalb von Modultests verwendet werden. Eine wichtige Regel des Modultests taucht immer wieder auf: Der einzelne Testfall soll so isoliert wie m"oglich sein, d.h. er soll nur das Objekt testen, das wir gerade unter der Lupe haben. Um diesem Ziel der gr"o"stm"oglichen Unabh"angigkeit eines Tests n"aher zu kommen, spielt Mock-Objekte eine gro"se Rolle.
\subsubsection{Klassen von JMock}
In {\em JMock} werden eine Reihe von Klassen implementiert, um Mock-Objekte f"ur {\em JUnit}  zu unterst"utzen. F"ur die Tests dieser Arbeit stehen die folgende Klassen zur Verf"ugung.
\begin{itemize}
	\item {\bf JMock} die {\em Runner-}Klasse f"ur {\em JUnit}
	\item {\bf Mockery} das Interface zum Erstellen der Mock-Objekten.
	\item {\bf JUnit4Mockery} eine Implementierung des Interfaces {\em Mockery}.
	\item {\bf Expectations} die Klasse zum Simulieren der Operationen der Mock-Objekten.
\end{itemize}
Im Abschnitt \ref{section:testservices} wird gezeigt, wie das Interface {\em INopEngineRep} (Repository) mit diesen Klassen von {\em JMock} zum Testen des Kern-Algorithmus als ein implementiertes Objekt simuliert wird.
\subsection{Test-Paket von Spring}
In dieser Arbeit wird {\em Spring} f"ur die Tests des Repositorys und der Integration der Schnittstellen der Dom"anen- und Persistenzschicht zur Verf"ugung gestellt. Das Test-Paket von {\em Spring} bietet die M"oglichkeit einer Zusammenarbeit mit {\em JUnit}. Durch die eigene Implementierung {\em SpringJUnit4ClassRunner} des Interfaces {\em Runner} von {\em JUnit} wird eine Klasse als eine von {\em JUnit} erkannte Test-Klasse deklariert. Damit k"onnen alle Funktionalit"aten von {\em Spring} in {\em JUnit} verwendet werden. Zum Erleichtern der Implementierung aller Tests ist noch eine Annotation \anno{ContextConfiguration}dieses Pakets zum Einsatz gekommen, mit der eine automatische Ladung der in der Konfigurationsdatei registrierten Beans erm"oglicht wird.


\section{Drei Test-Phasen zur Implementierung der Tests}
Zum Testen der Funktionalit"at der NOP-Engine werden die folgenden Aufgaben dargestellt,
\begin{enumerate}
	\item Verifizieren der Korrektheit des Kern-Algorithmus,
	\item "Uberpr"ufen der Verbindung mit der Datenbank bzw. des O/R Mapping,
	\item Messen der Funktionalit"aten der NOP-Engine an den Anforderungen.
\end{enumerate}
Zur Erf"ullung dieser Aufgaben werden alle Tests in 3 Test-Phasen aufgeteilt.  
 \subsection{Modultests ohne Datenbank f"ur den Kern-Algorithmus}
Die Hauptaufgabe dieser Arbeit ist  den Kern-Algorithmus der NOP-Engine zu implementieren. Bei der Entwurfsphase haben wir den Kern-Algorithmus in mehreren Services zerlegt. In der Tabelle \ref{table:firstunittest} werden die Services, die nacheinander von oben nach unten anhand ihrer Abh"angigkeit in der ersten Phase getestet werden sollen, dargestellt. Unter dem Motto "`{\em Implementierung hne Datenbank}"' \cite{Charlton09} von DDD wird die {\em Mock}-Technologie in dieser Phase angewendet, um die Operationen zum Zugreifen der Datenbank zu simulieren. Dadurch kann man sich bei der Implementierung der NOP-Engine zuerst nur auf den Kern-Algorithmus konzentrieren.\\
\TableFirstUnitTest

\subsection{Modultests f"ur das Repository}
In der zweiten Phase wird das Repository {\em INopEngineRep}, das die Persistenz-Objekte der NOP-Engine behandelt, getestet. Dabei soll das Schema der Datenbank schon vorhanden sein und richtig eingestellt werden. In DDD haben Repositorien eine gro"se Bedeutung. Sie sollen alle Dom"anenobjekte nach der Forderung eines Systems anbieten k"onnen, z.B. anlegen eines Objekts (Factory), herausfinden und abspeichern von Entit"aten (DAO), Verwalten von Services (Controller) usw.
%Zur Implementierung des NOP-Engine ist nur ein Repository \kc{INopEngineRep,}das als eine Fassade von DAO-Objekten die Entit"aten manipuliert, in dieser Arbeit zum Einsatz gekommen.
Sie werden als Fassaden \cite{Gamma94} aller Operationen, die die Dom"anenobjekte verwalten, betrachtet. Wegen der Wichtigkeit der Repositorien werden eine Reihe von Tests daf"ur zur Verf"ugung gestellt. Diese sind in der Tabelle \ref{table:secondunittest} dargestellt. \\
\TableSecondUnitTest\\
Bei dieser Phase soll das Repositroy {\em INopEngineRep} mit der Datenbank zusammenarbeiten, und die zweite  Aufgabe gleichzeitig erf"ullt werden.
\subsection{Integrationstests f"ur die NOP-Engine}
Diese Tests dienen dazu, alle Schnittstellen der NOP-Engine dahingehend zu "uberpr"ufen, ob sie alle Anforderungen, die im Kapitel \ref{chapter:requirment} herausgefunden werden, richtig erf"ullen. Alle getesteten Services bzw. das Repository werden in dieser Phase zusammengesetzt, um die Funktionalit"at an den funktionalen Anforderungen der NOP-Engine zu messen. Dabei werden alle Schnittstelle der Dom"anenschicht getestet. Als Voraussetzung dieses Tests m"ussen alle Services und das Repository getestet und in eine richtige Funktionsweise gebracht werden. Deswegen muss die Reihenfolge der drei Test-Phasen garantiert werden. Nach diesem Test wird die dritte Aufgabe parallel erledigt.

\section{Testf"alle der NOP-Engine}\label{section:testcase}
Angesichts der gro"sen Anzahl von Test-Aspekten werden viele Testf"alle zum Testen der NOP-Engine aufgebaut. Hierbei werden nur einige Abgeordnete vorgestellt, die f"ur die Implementierung der Tests wichtige Beitr"age geben k"onnen.
\subsection{Der Haupttestfall f"ur alle Tests}
Das Ziel dieses Testfalls ist ein Szenario, das den ganzen Ablauf des Gugubarra-Systems simuliert. Es wird aufgebaut, um die Korrektheit der Implementierung des Kern-Algorithmus zu verifizieren. Dieser Testfall besteht aus mehreren Teil-Testf"allen, die dazu zur Verf"ugung stehen, alle Services, so wie in der Tabelle \ref{table:firstunittest} dargestellt, zu "uberpr"ufen.  Im Folgenden wird dieser Testfall n"ahr spezifiziert.
\paragraph{Annahme: }
Wir nehmen an, dass es eine Web-Site gibt, auf dem das Gugubarra-System installiert ist. D.h. alle Web-Seiten der Web-Site sollten an den Mechanismus des Gugubarra-Systems angepasst werden und die Handlungsweisen der Benutzer sollten richtig notiert werden. Als Annahme ist die Anzahl der Web-Seiten gleich 10. \[P_1,\ldots,P_{10}\]
\paragraph{Vorbedingungen: }
Bez"uglich des Ablaufs des Gugubarra-Systems werden im Testfall folgende Vorbedingungen erf"ullt,
\begin{itemize}
	\item 5 Themen und Aktionen sind global definiert und abgespeichert. Sie sind $T_1, T_2, T_3, T_4$ und $T_5$ bzw. $a_1 = 1$, $a_2 = 5$, $a_3 = 2$, $a_4=2$ und $a_5 = 10$.
	Dabei bezeichnet $a_n = m$ die Aktion mit dem Index $n$ und einem Gewicht $m$.
	\item Damit werden noch 6 Zonen angelegt und ihre wichtigsten Eigenschaften in der Tabelle \ref{TableZonesInUnitTests} repr"asentiert.
	\TableZonesInUnitTests
\end{itemize}
Solche Themen, Aktionen und Zonen sollten auf der Designer-Seite vor der Berechnung von NOPs definiert werden.
\paragraph{Weitere Annahme: }
Zum Berechnen von NOPs ist eine weitere Annahme notwendig. F"ur einen Benutzer $u_1$ der Web-Site sollten 10 Benutzer-Sessionen schon vorhanden (und abgespeichert) sein, und der Verwalter hat bereits ein NOP-Projekt $np_1$ erstellt und damit ein NOP $nop_1$ f"ur $u_1$ berechnet. D.h. Zehn Benutzer-Sessionen haben zum NOP $nop_1$ beigetragen. Nach der Berechnung haben alle Themen vom $np_1$ ein Gewicht $0.5$.
\[nop_1 = \{T_1:0.5,\: T_2:0.5,\: T_3:0.5,\: T_4:0.5,\: T_5:0.5\}\]
Und der Zustand des NOP-Projekts $np_1$ sieht wie folgender aus.
\begin{description}
	\item[NOP-Projekt:] $np_1$
		\begin{itemize}
			\item Anzahl der berechneten Benutzer-Session: 10 
			\item Letzte Aktualisierungszeitpunkt: 02.01.2000 12:00:00
			\item {\bf {\em Strategie}}
				\begin{itemize}
					\item Parameter $a$: $0.3$
					\item Seitenregel: AVG
					\item Prominenter Faktor: unaktiviert
					\item Funktion f"ur den Parameter $f$: {\em DefaultCalculateFImp}\footnote{In diesem Fall wird nur die Funktion {\em DefaultCalculateFImp} f"ur den Parameter $f$ getestet.}
				\end{itemize}
		\end{itemize}
\end{description}
Die n"achste Kalkulation von NOPs f"ur $np_1$ ist von der zehnten Benutzer-Session abh"angig. Hierbei gilt diese Benutzer-Session und ihre wichtige Eigenschaften,
\begin{description}
	\item[Benutzer-Session:] $us_{10}$
\begin{itemize}
		\item Benutzer: $u_1$ 
		\item Index dieser Benutzer-Session: 10
		\item Startzeit: 01.01.2000 10:00:00
		\item Endzeit: 01.01.2000 10:16:04
		\item Summe der gesamten Zeitdauer aller berechneten Benutzer-Sessionen von $u_1$: 10000 Sekunden 
\end{itemize}
\end{description}
Der Wert der letzten Eigenschaft der Benutzer-Session $us_{10}$ schlie"st die Zeitdauer von $us_{10}$.
\paragraph{Simulation: } Nach der Annahme k"onnen wir hierbei die Handlungsweisen des Benutzers $u_1$ simulieren und als eine neue Benutzer-Session abspeichern.
\begin{enumerate}
	\item Der Benutzer $u_1$ loggt ein.
	\item Nach dem Einloggen ist der Benutzer $u_1$ zuerst auf der Web-Seite $P_1$ gelandet und hat zwei Aktionen $a_4$ bzw. $a_5$ ausgel"ost.
	\item Nach 10 Sekunden wird der Benutzer $u_1$ zur $P_2$ umgeleitet. Auf der $P_2$ werden die Aktionen $a_1$ und $a_4$ von ihm empfangen.
	\item Nach 50 Sekunden ist der Benutzer $u_1$ zur $P_3$ gegangen und auf dieser Seite 20 Sekunden geblieben. Inzwischen werden zwei Aktionen $a_1$ und  $a_2$ von $u_1$ ausgel"ost.
	\item Der Benutzer $u_1$ loggt aus.
\end{enumerate}
\figureTestcaseSimulation 
Der ganze Prozess der Simulation wird anschaulich in der Abbildung \ref{labelTestcaseSimulation} dargestellt. Er sollte als eine neue Benutzer-Session $us_{11}$ abgespeichert werden. Wobei der Index der neuen Benutzer-Session gleich 11 sein soll, und insgesamt 3 Zeitdauerinformationen und 4 Aktionsinformationen notiert werden, da die Zone $Z_5$ einen Zonenzustand "`OFF"' hat. Deshalb werden alle Aktionen in dieser Zone von Aktionsinformationen ausgeschlossen.
%\TableUserSessionTwo
\begin{description}
	\item[Benutzer-Session:] $us_{11}$
\begin{itemize}
		\item Benutzer : $u_1$ 
		\item Index dieser Benutzer-Session : 11
		\item Startzeit : 03.01.2000 13:00:00
		\item Endzeit : 03.01.2000 13:01:20
		\item Zeitdauerinformationen: $\{\:P_1: 10 \mbox{ Sekunde},\:P_2: 50 \mbox{ Sekunde},\:20 \mbox{ Sekunde}\}$
		\item Aktionsinformationen: $\{a_4\mbox{ in }z_3,\:a_5\mbox{ in }z_3,\:a_4\mbox{ in }z_3,\:a_1\mbox{ in }z_2\}$
\end{itemize}	
\end{description}
Ausgehend von der Start- und Endzeit der Benutzer-Session $us_{11}$ wird berechnet,  dass die Zeitdauer von $us_{11}$ 80 Sekunden, und die Entfernung zwischen dem Abschluss von $us_{10}$ und dem Start von $us_{11}$ 0.30197751 Woche ist. Sie sollten als Eingabeparameter der Funktion f"ur den Parameter $f$ bei der n"achsten Berechnung von NOPs zur Verf"ugung stehen.
\paragraph{Berechnung von NOPs:}
Schlie"slich berechnet der Verwalter f"ur das NOP-Projekt $np_1$ die neue NOPs.
\paragraph{Nachbedingungen: }  Nach der neuen Berechnung wird ein neues NOP $nop_2$ f"ur den Benutzer $u_1$ in Bezug auf das NOP-Projekt $np_1$ von der NOP-Engine generiert, und die Anzahl der berechneten Benutzer-Session von $np_1$ um 1 (gleich 11) erh"oht. 
\[nop_2 = \{T_1:0.47393181,\: T_2:0.47404545,\: T_3:0.48381818,\: T_4:0.48429545,\]
\[\hspace{-6.8cm}T_5:0.46448863\}\]
%\TableNOPTwo
Alle Gewichte der Themen des $us_2$ sind nach den Formeln \ref{formulaDurP} bis \ref{formulaNewP} manuell berechnet. Angesichts des Rundungsfehlers in JAVA wird die Genauigkeit dieser Ergebnisse nur bis zur achten Stelle nach dem Komma "ubergenommen.\\\\
Alle obengenannten Objekte sind f"ur die zweite und dritte Test-Phase auch wiederverwendbar. Besonders beim Integrationstest wird das ganze Szenario "ubergenommen, um die Schnittstelle $calculateNops$ des Interfaces {\em INopEngine} zu testen.

\subsection{Zerlegung des Haupttestfalls in kleinen Teil-Testf"allen zur Anpassung an die verschiedenen Tests}
Zur Anpassung an die verschiedenen Tests f"ur die NOP-Engine wird der Haupttestfall in mehreren kleinen Teil-Testf"allen zerlegt. Wegen der gro"sen Anzahl wird nur der Teil-Testfall f"ur das Service {\em IParamFService} als Beispiel in dieser Arbeit gegeben.
\subsubsection{Teil-Testfall zum Testen des Services {\em IParamFService}}\label{section:tff}
Die Schnittstelle {\em getValue} des Services {\em IParamFService} ist von drei Parametern abh"angig, die durch die Benutzer-Session $us_{10}$ und $us_{11}$ erhalten werden k"onnen.
\begin{itemize}
\item Die Anzahl der berechneten Benutzer-Sessionen in Bezug auf das NOP-Projekt $np_1$: 10
\item Die Zeitdauer zwischen dem Schluss von $us_{10}$ und dem Start von $us_{11}$: 0.30197751 Woche
\item Die Summe der gesamten Zeitdauer der berechneten Benutzer-Sessionen: 10080 Sekunden
\end{itemize}
Anhand der Strategie im eingegebenen NOP-Projekt $np_1$ soll die Funktion {\em DefaultCalculateFImp} f"ur den Parameter $f$ getestet werden. Durch die Funktion {\em DefaultCalculateFImp} und die obenerw"ahnten drei Parameter wird der Parameter $f$ ausgewertet, und gleich 1 gesetzt (Nachbedingung).

%\subsection{Testf"alle f"ur die Nullobjekte}
%Bei der Implementierung des NOP-Engine werden einige Nullobjekte \cite{Martin97} eingef"uhrt, um an das Mechanismus zur Darstellung der Dom"anenobjekten in JSF anzupassen. Die in unserem Projekt angewendete drei Nullobjekte sind,
%\begin{itemize}
%\item \kc{EmptyNop}
%\item \kc{EmptyUserSession}
%\item \kc{EmptyResultList} 
%\end{itemize}
%Sie sollen von dem Repository verwaltet und in der zweiten Test-Phase getestet werden. Wegen der "Aquivalenz der drei Testf"allen wird In dieser Arbeit nur der Testfall f"ur $EmptyNop$ vorgestellt.
%\subsubsection{Testfall f"ur EmptyNop}
%In diesem Fall wird ein neues NOP-Projekt $np_2$ gefordert. Im Vergleich mit $np_1$ hat $np_2$ die selbe Werte f"ur alle Eigenschaften au"ser $lastUpdate$.\\
%{\bf NOP-Projekt } : $np_2$
%		\begin{itemize}
%			\item \kc{Letzte Aktualisierungszeitpunkt}:  0 Millisekunden
%		\end{itemize}
%wobei die letzte Aktualisierungszeit kleiner als die Startzeit aller vorhandenen Benutzer-Sessionen sein soll. Angenommen wird, der Verwalter will den Inhalt des aktuellen NOPs von dem Benutzer $u_1$ in Bezug auf $np_2$ ansehen. Als die Nachbedingung wird ein Leeres NOP von der NOP-Engine zur"uckgegeben.
%\subsection{Testf"alle f"ur den Grenzwert-Tests}
%In der Test-Phase 1 stehen noch mehrere Grenzwert-Tests daf"ur zur Verf"ugung, die Korrektheit der Berechnung der ersten Benutzer-Session eines Benutzers bez"uglich eines NOP-Projekts f"ur alle Services zu verifizieren, z.B. Berechnen des NOPs f"ur das NOP-Projekt $np_1$.

\section{Implementierung der Tests}
Zur Implementierung der Tests werden die quelloffenen Bibliotheken \kc{JUnit,}\kc{JMock}und das Test-Paket von \kc{Spring}angewendet, um die automatisierten Modul- und Integrationstests aufzubauen bzw. die obenerw"ahnten Testf"alle zu implementieren. F"ur die Tests der NOP-Engine werden insgesamt $5$ Klassen erstellt, die "uber eigene Verantwortlichkeiten (Siehe die Tabelle \ref{table:testclassunittest}) verf"ugen.
\TableTestClass
\subsection{Die Klasse {\em NopEngineTestBase}}
Die Klasse $NopEngineTestBase$ ist die Superklasse aller anderen Test-Klassen, und verwaltet die Test-Objekte, die von den obenerw"ahnten Testf"allen gebraucht werden. Sie ist keine richtige Test-Klasse, d.h. sie kann nicht als ein Modultest allein ausgef"uhrt werden. Zum Erleichtern der Implementierung wird sie noch mit der neuen Verantwortlichkeit - Einstellen der globalen Variablen - als eine normale JAVA-Klasse dargestellt.
\subsubsection{Einstellen der globalen Variablen}
In allen drei Test-Phasen werden die folgenden Variablen immer angewendet,
\begin{itemize}
\item eine Instanz von \kc{NopEngineFactory}, 
\item ein \kc{double}Wert f"ur den Rundungsfehler, und
\item alle Test-Objekte, die von dem Haupttestfall gefordert werden. 
\end{itemize}
Sie sollen als \kc{static}eingestellt werden, um sie an die neue Anwendungsweise von {\em JUnit}  $4.0+$ anzupassen.  Wegen des Rundungsfehlers\footnote{Ausgehend von der Praxis ist der {\em double} Typ in JAVA nur bis zur achten Stelle nach dem Komma richtig zu berechnen.} bei der Kalkulation von {\em double} in JAVA wird ein Toleranzwert gleich $0.000000001$ gesetzt. Au"serdem wird noch eine Instanz von \kc{NopEngineFactory}gefordert, um die Test-Objekte zu erzeugen.
%\includeJavaCode{chapters/test/globalVariableAsignment.java}{Einstellung der globalen Variablen f"ur alle Tests}{jc:gv}
\subsubsection{Verwalten der Test-Objekte}
Wegen der unterschiedlichen Aufgaben der Tests sollen die Test-Objekte bei jeder Test-Phase neu initialisiert werden. Insbesondere bei der zweiten Test-Phase werden die Test-Objekte nach jedem Test erneut zugewiesen. Zum Verwalten solcher globalen Test-Objekten werden zwei statische Methoden \kc{init} und \kc{dispose} in dieser Klasse eingef"ugt, wobei die Methode \kc{init} f"ur das Anlegen der Test-Objekten zust"andig und \kc{dispose} zum Freigeben solcher Objekten vorgesehen ist.

\subsection{Die Test-Klasse {\em TestServices}}\label{section:testservices}
Diese Klasse ist f"ur die Modultests in der ersten Test-Phase zust"andig, und steht f"ur alle Tests der Services zur Implementierung des Kern-Algorithmus zur Verf"ugung. Bei dieser Test-Phase ist das Interface {\em INopEngineRep} des Repositorys noch nicht implementiert. Um die Tests durchzuf"uhren verwenden wir die quelloffene Bibliothek {\em JMock} zum Simulieren des Repositorys. 
\subsubsection{Anwendung von \kc{JMock}zum Simulieren des Repositorys}
Mit Hilfe von {\em JMock} wird das Interface \kc{INopEngineRep}durch ein Mock-Objekt simuliert. Wir geben hier ein Beispiel, das ein Teil der Tests in der Klasse {\em TestServices} ist.\\
\includeJavaCode{chapters/test/jmock_first_test.java}{Tests mit JMock}{jc:jmock}
Anstatt der {\em Runner-}Klasse von \junit wird die eigene {\em Runner} von {\em JMock} zur Deklaration der Klasse {\em TestServices} als eine Test-Klasse von {\em JUnit} verwendet. Mit der Deklaration \kc{@RunWith(JMock.class)}wird \junit mitgeteilt, dass die Tests dieser Klasse die {\em JMock}-Tests sind. Die Variable {\em ctx} ist eine Instanz der Klasse {\em JUnit4Mockery}, und f"ur die Erzeugung der Mock-Objekten zust"andig. In der Zeile 16 wird ein Mock-Objekt f"ur das Interface \kc{INopEngineRep}erstellt. In dem Block \mbox{"`Expections"'} werden die Zugriffe "uber zwei Schnittstellen des Mock-Objekts von \mbox{\kc{INopEngineRep}}mit den Paaren \kc{allowing}und \kc{will}deklariert, wobei
\begin{itemize}
\item {\em allowing} die Zugriffe auf eine Methode einer Mock-Objekt erlaubt, und
\item {\em will} das erwartete Ergebnis der von {\em allowing} erlaubten Methode einstellt.
\end{itemize}
Die Eingaben und Ausgaben beider Schnittstellen m"ussen als {\bf final} definiert und vor der Deklaration von {\em Expectations} zugewiesen werden. Dieses Mock-Objekt bzw. seine zwei simulierte Schnittstellen stehen f"ur mehrere Tests in dieser Test-Phase zur Verf"ugung und sind w"ahrend der Tests unver"anderbar. Infolgedessen sollen dieses Mock-Objekt vor allen Tests in dieser Test-Phase einmalig erzeugt, und in die statische Methode, die mit \kc{@BeforeClass}bezeichnet wird, eingepackt werden. Wobei die Annotation \anno{BeforeClass}von {\em JUnit} f"ur die Deklaration einer Methode, die vor allen Tests in dieser Test-Klasse nur einmalig ausgef"uhrt werden soll, zur Verf"ugung steht.
\subsubsection{Anwendung der globalen Test-Objekte}
In dieser Test-Phase lassen sich die Zust"ande aller globalen Test-Objekte nach jedem Test nicht ver"andern. Solche Objekte werden f"ur alle Tests nur einmalig erstellt. Infolgedessen wird die Methode {\em init} in der mit der Annotation \anno{Before}bezeichneten Methode {\em beforeTest} aufgerufen, und {\em dispose} in der mit \anno{After}deklarierten Methode {\em afterTest} ausgef"uhrt.\\
\includeJavaCode{chapters/test/beforeaftertest.java}{Deklaration einer Test-Klasse f"ur {\em JUnit} durch {\em Spring}}{jc:junitbeforeafter}
\subsubsection{Anwendung der Assertionen zum Messen der realen Werte an die erwarteten Werte}
In jedem Test sollen Assertionen von {\em JUnit} verwendet werden, um die realen Werte im Vergleich zu den erwarteten Werten zu messen, und die Korrektheit der Implementierung zu gew"ahren. Zum Beispiel steht der Test {\em testParamFService}, der f"ur die Verifikation der Funktion {\em DefaultCalculateFImp} f"ur den Parameter $f$ mit dem im Abschnitt \ref{section:tff} vordefinierten Teil-Testfall zur Verf"ugung. Im folgenden Codeblock wird dieser Teil-Testfall mit der Assertion {\em assertEqual} implementiert.\\
\includeJavaCode{chapters/test/testf.java}{Der Test zur Verifikation der Funktion f"ur den Parameter $f$}{jc:tf}


\subsection{Die Test-Klasse {\em TestRepository}}
Die Klasse {\em TestRepository} steht f"ur die Tests in der zweiten Test-Phase zur Verf"ugung. Dabei soll das Interface {\em INopEngineRep} des Repositorys mit der Klasse {\em NopEngineRepImp} implementiert, und mit der richtigen Datenbank getestet werden. In dieser Test-Klasse wird die {\em Runner}-Klasse von \spring verwendet. Durch die Annotation {\em @ContextConfiguration} wird die Konfigurationsdatei TestContext.xml automatisch geladen. Dabei gibt es im Vergleich mit dem Inhalt der Konfigurationsdatei von {\em Spring}, die im Abschnitt \ref{imp:integration} definiert wurde, keinen Unterschied.\\
\includeJavaCode{chapters/test/spring_test1.java}{Deklaration einer Test-Klasse f"ur {\em JUnit} durch {\em Spring}}{jc:sptestde}
Die Annotation \kc{@Resource}dient zu einer automatischen Ladung des Objekts \kc{rep,} das in der Konfigurationsdatei von \spring als eine \kc{Bean}mit dem selben Namen registriert ist. Was f"ur ein {\em Modifier}\footnote{In JAVA werden alle Variablen, Methoden und Klassen mit einem {\bf Modifier} deklariert, z.B. {\bf public, private und protected usw.}} die Variable {\em rep} ist,  spielt hier keine Rolle.\\
\includeJavaCode{chapters/test/spring_test2.java}{Automatische Ladung einer vordefinierten Bean durch {\em Spring}}{jc:sptestre}
Eine neue Methode {\em recoveryDB} wird f"ur alle Tests in dieser Klasse zur Verf"ugung gestellt, um nach jedem Test in dieser Klasse den Zustand der Datenbank  wiederherzustellen und die anderen Tests weiter durchf"uhren zu lassen. Deshalb soll diese Methode in der mit der Annotation {\em @After} von {\em JUnit} bezeichneten Funktion {\em afterTest} aufgerufen, und nach jedem Test automatisch von {\em JUnit} erneut ausgef"uhrt werden.\\
\includeJavaCode{chapters/test/recoveryDB.java}{Die Methode zum Wiederherstellen des Zustands der Datenbank}{jc:sptestredb}
In dieser Test-Klasse sollen alle Tests, die in der Tabelle \ref{table:secondunittest} dargestellt sind, implementiert, und als {\em JUnit}-Tests mit der Annotation \anno{Test}deklariert werden.
%Im folgenden Codeblock werden alle Tests, die in der Tabelle \ref{table:secondunittest} dargestellt sind, implementiert\footnote{Diese Tests werden durch die Namen der Test-Methoden beschrieben.}, und als {\em JUnit}-Tests mit der Annotation \kc{@Test}deklariert.\\
%\includeJavaCode{chapters/test/test_rep.java}{Tests der Klass {\em TestRepository}}{jc:sptests}


\subsection{Die Test-Klasse {\em TestNopEngine}}
Alle Tests f"ur die dritte Test-Phase werden in die Klasse \kc{TestNopEngine} eingepackt. Sie dient dazu, die Funktionalit"aten der NOP-Engine an die Anforderungen aus dem Kapitel \ref{chapter:requirment} zu messen. Alle Schnittstellen des Interfaces {\em INopEngine} sollen in dieser Test-Klasse getestet werden. F"ur die Konfiguration solcher Tests gibt es im Vergleich zur zweiten Test-Phase keinen Unterschied. Nur das zu testende Interface wird statt {\em INopEngineRep} als {\em INopEngine} gesetzt.\\
\includeJavaCode{chapters/test/testThreeth.java}{Deklaration der zu testenden Interface {\em INopEngine}}{jc:testne}

\subsection{Durchf"uhrung aller drei Test-Klassen zur Verifikation der Korrektheit der "Anderungen und Refaktorisierungen}
Bei der Implementierung der NOP-Engine und auch der Tests selbst sind "Anderungen oder Refaktorisierungen st"andig erforderlich. Nach jeder richtigen "Anderung oder Refaktorisierung sollen alle drei Test-Klassen jeweils ausgef"uhrt werden, um schlechte Nebenwirkungen zu vermeiden. Zum vereinfachen dieser Arbeit setzen wir die drei Test-Klassen als einen {\em Suite}-Test von {\em JUnit}, zusammen. Sie k"onnen automatisch nacheinander durchgef"uhrt werden k"onnen. In der Liste \ref{jc:st} ist diese Klasse dargestellt.\\
\includeJavaCode{chapters/test/suite_test.java}{Suite-Tests f"ur alle Modul- und Integrationstests}{jc:st}

\section{Zusammenfassung}
In diesem Kapitel werden Modul- und Integrationstests in das Projekt eingef"uhrt, um die Korrektheit des Kern-Algorithmus zu verifizieren, die Verbindung mit der Datenbank bzw. das O/R Mapping zu "uberpr"ufen, und die Funktionalit"aten der NOP-Engine an die Anforderungen zu messen. Dabei werden mehrere Testf"alle f"ur die Tests aufgebaut, und einige davon in dieser Arbeit detailliert vorgestellt. Zur Implementierung der Tests werden alle Tests in drei Test-Klassen entsprechend der vordefinierten drei Test-Phasen aufgeteilt, und mit den quelloffenen JAVA-Bibliotheken, sowie {\em JUnit}, {\em JMock}, bzw. dem Test-Paket von \spring realisiert.




